1. Field of the Invention
The present invention relates to a communication system. More particularly, the present invention relates to a system and method for transmitting and receiving ranging information in a sleep mode in a communication system.
2. Description of the Related Art
Generally, communication systems are being developed to support services capable of transmitting and receiving a large volume of data to/from Mobile Stations (MSs) at high speed. An example of the communication systems comprises an Institute of Electrical and Electronics Engineers (IEEE) 802.16e communication system. The IEEE 802.16e communication system provides a normal mode operation in which communication is continually maintained between an MS and a Base Station (BS).
In the IEEE 802.16e communication system, an MS is always monitoring the DownLink (DL) to receive data from a BS. Accordingly, when the BS has no data to transmit to the MS or when the MS has no data to transmit to the BS, the MS continuously monitors the downlink and is therefore constantly consuming power. Thus, the MS is undesirably consuming power when the BS has no data to transmit to the MS or when the MS has no data to transmit to the BS. In particular, since the IEEE 802.16e communication system considers mobility of the MS, the power consumption of the MS acts as an important factor in the performance of the entire system. Therefore, a sleep mode operation between an MS and a BS, and an awake mode operation corresponding to the sleep mode operation have been proposed to minimize the MS's power consumption. In addition, to cope with a change in the state of a channel between the BS and the MS, the MS periodically performs a ranging operation with the BS in order to correct a timing offset, a frequency offset and a power level.
With reference to FIG. 1, a description will now be made of a conventional message exchange process between an MS and a BS in a sleep mode operation performed in a communication system.
FIG. 1 is a diagram illustrating a conventional process of performing a sleep mode operation in a communication system.
Referring to FIG. 1, when an MS 100 desires to transition from the awake mode to the sleep mode, the MS 100 transmits a MOBile_SLeeP-REQuest (MOB_SLP-REQ) message to a BS 110 in step 101. Upon receipt of the MOB_SLP-REQ message, the BS 110 determines whether it will grant the transition to the sleep mode of the MS 100 considering a state of the BS 110 itself and a state of the MS 100, and transmits a MOBile_SLeeP-ReSPonse (MOB_SLP-RSP) message to the MS 100 according to a result of the determination in step 103. Herein, the MOB_SLP-RSP message comprises a Listening Window parameter. Further, if the BS 110 has data to transmit to the MS 100 in the listening window of the sleep mode, the BS 110 transmits a MOBile_TRaFfic-INDication (MOB_TRF-IND) message comprising an identifier of the MS 100 to the MS 100 in the listening window.
Upon receiving the MOB_SLP-RSP message from the BS 110, the MS 100 starts a sleep mode operation according to the MOB_SLP-RSP message. The MS 100 recognizes the operation it will perform according to the Listening Window parameter included in the MOB_SLP-RSP message. In addition, even though the MS 100 is operating in the sleep mode, the MS 100 can immediately transition from the sleep mode to the awake mode when the MS 100 has data to transmit to the BS 110.
Meanwhile, the BS 110 transmits a MOB_TRF-IND message in the listening window of the sleep mode in step 105. Herein, the MS's identifier may not be comprised in the MOB_TRF-IND message. In this case, since the MOB_TRF-IND message is a message that does not correspond to the MS 100, the MS 100 decodes the MOB_TRF-IND message, and then again performs the sleep mode operation, upon determining that its identifier is not comprised in the message.
After a lapse of a predefined amount of time, if the BS 110 has data to transmit to the MS 100 in the listening window of the sleep mode, it transmits a MOB_TRF-IND message comprising an identifier of the MS 100 to the MS 100 in step 107. Since the MOB_TRF-IND message is a message corresponding to the MS 100, the MS 100 decodes the MOB_TRF-IND message, and then transitions to the awake mode and receives the data from the BS 110, upon determining that its identifier is comprised in the message.
After the data transmission/reception of the MS 100 and the BS 110 is completed, the MS 100 and the BS 110 again exchange a MOB_SLP-REQ message and a MOB_SLP-RSP message in order to transition back to the sleep mode. Since the MS 100 and the BS 110 exchange the MOB_SLP-REQ message and the MOB_SLP-RSP message for the mode transition to the sleep mode, they perform an unnecessary transmission of the messages, causing a waste of UpLink (UL) and DL resources and power consumption. In addition, the MS 100 performs bandwidth ranging by transmitting a BandWidth-REQuest (BW-REQ) message in order to be allocated a bandwidth over which it will transmit the MOB_SLP-REQ message to the BS 110. Thus, the MS 100 may delay the time required for performing a mode transition to the sleep mode.
Meanwhile, the IEEE 802.16e communication system defines the following messages in order to support the above-stated sleep mode operation and awake mode operation.
(1) MOB_SLP-REQ Message
The MOB_SLP-REQ message is a message that the MS transmits to the BS when the MS 100 desires to transition from the awake mode to the sleep mode. The MOB_SLP-REQ message comprises therein the parameters, or Information Elements (IEs), that the MS requires to make a mode transition to the sleep mode, and an exemplary format of the MOB_SLP-REQ message is shown in Table 1.
TABLE 1SyntaxSize (bits)NotesMOB_SLP-REQ_Message_format( ) { Management message type = 508 Number of Classes8Number ofpower savingclasses. for (i=0; i<Number of Classes; i++) { Definition1 Operation1 Power_Saving_Class_ID6 if (Operation = 1) {  Start_frame_number6  Reserved2 { if (Definition = 1) {  Power_Saving_Class_Type2  Direction2  Traffic_triggered_wakening_flag1  Reserved3  Initial-sleep window8  listenting-window8  final-sleep window base10  final-sleep window exponent3  Number_of_Sleep_CIDs3  for (i=0; i<Number_of_Sleep_CIDs; i++){  CID16 } } TLV encoded informationvariable}
As shown in Table 1, the exemplary MOB_SLP-REQ message comprises a plurality of IEs.
‘Management Message Type’ refers to information indicating a type of the transmission message. When ‘Management Message Type’ is 50, it denotes that the transmission message is the MOB_SLP-REQ message. ‘Number of Classes’ refers to information indicating the number of power saving classes to be comprised in the MOB_SLP-REQ message. ‘Definition’ refers to information indicating one of a definition of a new power saving class or a definition of an old class.
‘Operation’ refers to information indicating whether the power saving class is activated or deactivated. ‘Power Saving_Class_ID’ refers to information indicating an identifier for indicating a power saving class indicating the current operation. ‘Start_Frame_Number’ refers to information indicating the time that a corresponding power saving class is to be activated.
When ‘Definition’ is 1, IEs indicating characteristics of the corresponding Power_Saving_Class_ID are as follows.
<1> Power_Saving_Class_Type: It refers to information indicating a type of a corresponding power saving class. Herein, types of the corresponding power saving class are as follows.
1) Type 1: It is a class based on the conventional sleep mode operation. That is, the MS transitions to the awake mode when data transmission/reception occurs in a listening window or when it receives a MOB_TRF-IND message comprising an affirmative indication.
2) Type 2: It is a class that has a fixed sleep window, performs data transmission/reception in a listening window, and performs data transmission/reception in the next listening window after the fixed sleep window.
3) Type 3: While Type 1 and Type 2 continually maintain the sleep mode unless a mode transition request message is received, Type 3 denotes a class that automatically ends the sleep mode after one sleep mode operation, i.e., after one sleep window. It may be used for a management message or multicast traffic.
<2> Direction: It refers to information indicating uplink or downlink.
<3> TRF-IND_Required: The TRF-IND_Required refers to information indicating use/nonuse of the MOB_TRF-IND message when it is necessary to deactivate a corresponding power saving class of the MS. If it is necessary to use the MOB_TRF-IND message, the BS allocates a SLeeP Identifier (SLPID) to the MS. Then the MS receives a MOB_TRF-IND message from the BS during the listening window, and checks existence/nonexistence of the SLPID which is mapped to the corresponding power saving class. In this manner, the MS determines whether it will deactivate the corresponding power saving class.
<4> Traffic_Triggered_Wakening_Flag (TTWF): It is applied only to Type 1, which is a type of the corresponding power saving class indicated by the above-stated power saving class type.
More specifically, the TTWF is used when the MS desires to maintain the sleep mode even though data occurs in the listening window. That is, when the TTWF is 0, the MS transmits/receives data during the listening window, and transitions back to the sleep mode at the time the listening window expires, i.e., at the time the sleep window starts.
When the BS desires to transmit a Medium Access Control (MAC) Service Data Unit (SDU) for a corresponding power saving class during the listening window, when the MS transmits a BW-REQ message for a connection for the corresponding power saving class, or when the MS receives a MOB_TRF-IND message comprising affirmative indication, i.e., an identifier of the MS, from the BS, the MS can end the sleep mode and then transition to the awake mode. Alternatively, the MS can end the sleep mode through transmission/reception of the MOB_SLP-REQ message and the MOB_SLP-RSP message.
Meanwhile, when the TTWF is 1, the MS should unconditionally end the sleep mode and make a mode transition to the awake mode, when it receives a Packet Data Unit (PDU) from the BS during the listening window, or when it receives a management message for ending the sleep mode, for example, a MOB_SLP-RSP message or a DL Sleep Control Extended Subheader (SCES).
In addition, the MS should unconditionally end the sleep mode and make a mode transition to the awake mode when data occurs in the MS itself or when it transmits to the BS a management message for ending the sleep mode, i.e., a MOB_SLP-REQ message or a bandwidth request message with a UL Sleep Control Header (SCH). In other words, for TTWF=1, the MS transitions to the awake mode when traffic occurs during the listening window or when a management message occurs.
As described above, the TTWF is used when the MS desires to maintain the sleep mode and perform data transmission/reception during the listening window, according to Type 1 or Type 2 which is a type of the corresponding power saving class.
<5> Initial-Sleep Window: It refers to information indicating a start value that starts the sleep window.
<6> Listening Window: It refers to information indicating a required listening window. The MS receives a MOB-TRF-IND message from the BS when it transmits/receives traffic during the listening window, or when the TRF-IND_Required is 1.
<7> Maximum Sleep Window: The maximum value of the sleep window is determined using a final-sleep window base and a final-sleep window exponent, i.e., using two parameters. That is, the maximum sleep window value is determined as (final-sleep window base)*2^(final-sleep window exponent).
<8> Number_of_CIDs: It refers to information indicating the total number, Number_of_Sleep_Connection IDs, of sleep Connection Identifiers (CIDs) associated with the corresponding power saving class, and indicates the number of unicast CIDs.  <9> CID: It denotes a sleep CID associated with the corresponding power saving class.
(2) MOB_SLP-RSP Message
The MOB_SLP-RSP message is a message that the BS transmits to the MS along with information indicating whether it will grant an MS's mode transition to the sleep mode considering a state of the BS itself and a state of the MS, or a message that the BS transmits to the MS along with an unsolicited instruction. The MOB_SLP-RSP message comprises therein the parameters, or IEs, that the MS requires to operate in the sleep mode, and an exemplary format of the MOB_SLP-RSP message is shown in Table 2.
TABLE 2SizeSyntax(bits)NotesMOB SLP RSP Message format( ) { Management message type = 518 Number of Classes8Number of power savingclasses for (i=0; i<Number_of_Classes; i++) { Length of data7 Sleep Approved1 Definition1 Operation1 Power_Saving_Class_ID6 if (Sleep Approved == 1) {  if (Operation = 1) {  Start_frame_number6  Reserved2  } if (Defintion = 1) {  Power_Saving_Class_Type2  Direction2  Initial-sleep window8  listening window8  final-sleep window base10  final-sleep window exponent3  TRF-IND required1  Traffic_triggered_wakening_flag1  Reserved1  if (TRF-IND required) {  SLPID10  Reserved2  }  Number of CIDs1  for (i=0; i<Number_of_CIDs; i++) {  CID16  }  if (MHDO or FBSS capability enabled) {If MHDO orFBSS capabilityis enabled in theREG-REQ/RSPmessageexchange  Maintain Diversity Set and Anchor1BS  if (Maintain Diversity Set and AnchorBS) {  MHDO/FBSS duration(s)3  }  } }  PaddingvariableIf needed foralignment tobyte boundary  if (Operation = 1) {  Power Saving Class TLV encodedvariableinformation  } }else{In case Sleep  Approved == 0 REQ-duration8 } TLV encoded informationvariable}
As shown in Table 2, the exemplary MOB_SLP-RSP message comprises a plurality of IEs. The MOB_SLP-RSP message is also a message which is transmitted based on a Basic CID of the MS.
‘Management Message Type’ refers to information indicating a type of the transmission message. When ‘Management Message Type’ is 51, it means that the transmission message is the MOB_SLP-RSP message. ‘Length_of_Data’ refers to information indicating the number of bytes of a power saving class. ‘Sleep_Approved’ is information indicating approval/disapproval of an activation or deactivation request for a corresponding power saving class of the MS. Herein, when a value of the Sleep_Approved is ‘1’ and a value of ‘Operation’ is ‘1’ (activation), ‘Start_frame_number’ is comprised. When a value of the Sleep_Approved is ‘1’ and a value of ‘Definition’ is ‘1’, Power_Saving_Class_Type, Direction, Initial-Sleep Window, Listening Window, final-sleep window base, final-sleep window exponent, MOB_TRF-IND required, and TTWF are comprised.
Herein, when a value of the Definition is ‘1’, the same IEs are comprised as the IEs that are comprised when a value of the Definition described in connection with the MOB_SLP-REQ message is ‘1’. Further, the following IEs are additionally comprised.
<1> SLPID: In the case where TRF-IND Required is set to ‘1’, if the BS transmits to the MS a MOB_TRF-IND message comprising an affirmative indication, i.e., an identifier of the MS, as described in connection with the MOB_SLP-REQ message, the BS allocates a SLPID for allowing the MS to recognize the affirmative indication when it receives the MOB_TRF-IND message.
<2> Macro Diversity HandOver/Fast Base Station Switching duration (MDHO/FBSS duration): It refers to information indicating a valid duration of an adjacent diversity BS set and anchor BS information when MDHO/FBSS between a BS and an MS is supported, or when the MS activates the corresponding power saving class.
In addition, the MOB_TRF-IND required is applied only in the power saving class Type 1, and it indicates that the BS should transmit at least one MOB_TRF-IND message to the MS during every listening window.
(3) MOB_TRF-IND Message
The MOB_TRF-IND message is a message that the BS transmits to the MS during the listening window, and a message indicating existence/nonexistence of the data the BS will transmit to the MS. The MOB_TRF-IND message, unlike the MOB_SLP-REQ message or the MOB_SLP-RSP message, is a message which is transmitted in a broadcasting or multicasting manner. An exemplary format of the MOB TRF-IND message is shown in Table 3.
TABLE 3SyntaxSize (bits)NotesMOB_TRF-IND_Message_format( ) { Management message type = 528 FMT1 if (FMT== 0) { SLPID Group Indication bit-map32N-th bit of SLPID-Groupinformation bit-map {MSBcorresponds to N = 0} isallocated to SLPID Group thatincludes MS with SLPIDvalues from N * 32 toN * 32 + 31.Meaning of this bit0: There is no traffic for allthe 32 MSs which belong tothe SLPID-Group1: There is traffic for at leastone MS in SLPID-Group Traffic Indication BitmapvariableTraffic Indication bit-mapcomprises the multiples of 32-bit long Traffic Indication unitA Traffic Indication unit for32 SLPIDs is added toMOB_TRF-IND messagewhenever its SLPID Group isset to 1. 32 bits of TrafficInidcation Unit (starting fromMSB) are allocated to MS inthe ascending order of theirSLPID values:0: Negative indication1: Positive indication }else{ Num_Pos8Number of CIDs following for (i=0; i<Num_Pos: i++) {  SLPIDs10 }  } PaddingvariableIf needed, for alignment tobyte boundary TLV encoded Itemsvariable}
As shown in Table 3, the exemplary MOB_TRF-IND message is a message indicating existence/nonexistence of the data the BS will transmit to the MS. The MS receives the MOB_TRF-IND message during the listening window, and determines whether it will transition from the sleep mode to the awake mode, or will continue to maintain the sleep mode.
If the MS makes a mode transition to the awake mode, the MS checks frame synchronization. When the frame sequence number that the MS expects is not coincident with the current frame sequence number, the MS can request retransmission of the data lost in the awake mode. However, the MS can continue to maintain the sleep mode, when the MS has failed to receive the MOB_TRF-IND message during the listening window, or when the MS has received a message comprising non-affirmative indication, for example, information indicating nonexistence of the data the MS will receive, even though it has received the MOB_TRF-IND message.
Meanwhile, the MOB_TRF-IND message also comprises a plurality of IEs. ‘Management Message Type’ is information indicating a type of the transmission message. When ‘Management Message Type’ is 52, it denotes that the transmission message is the MOB_TRF-IND message. ‘FMT’ indicates whether it will use an SLPID bitmap format or an SLPID format as a format of the MOB_TRF-IND message.
(4) BW-REQ and UL Sleep Control Header
The BW-REQ and UL Sleep Control header is a bandwidth request header that the MS transmits to the BS in order to activate or deactivate the power saving class. When deactivating the corresponding power saving class, the MS can make a bandwidth request for a corresponding connection together. An exemplary format of the BW-REQ and UL Sleep Control header is shown in Table 4.
TABLE 4
The IEs of the BW-REQ and UL Sleep Control header, shown in Table 4 as an example, have been described in connection with the MOB_SLP-REQ message, so a detailed description thereof will be omitted herein.
(5) Downlink (DL) Sleep Control Extended Subheader
The DL Sleep Control Extended Subheader is a subheader that the BS transmits to the MS in order to activate or deactivate the power saving class. An exemplary format of the DL Sleep Control Extended Subheader is shown in Table 5.
TABLE 5NameSize (bits)DescriptionPower_Saving_Class_ID6Power Saving Class ID thiscommand refers to.Operation11 = activate Power Saving Class0 = de-activate Power Saving ClassFinal_Sleep_Window_Exponent3For Power Saving Class Type IIIonly: assigned factor by which thefinal-sleep window base ismultiplied in order to calculate theduration of single sleep windowrequested by the message.Final_Sleep_Window_Base10For Power Saving Class Type IIIonly: the base for duration of singlesleep window requested by themessage.Reserved4
The IEs of the DL Sleep Control Extended Subheader, shown in Table 5, have been described in connection with the MOB_SLP-RSP message, so a detailed description thereof will be omitted herein.
As described above, in the sleep mode operation of the IEEE 802.16e communication system, regarding the power saving class Type 1, the MS can maintain the sleep mode or deactivate the power saving class, when it receives a MAC SDU from the BS during the listening window according to the TTWF. However, when the MS intends to maintain the sleep mode, a time when the MS desires to make a mode transition back to the sleep mode after the listening window expired is not yet established. In addition, the TTWF is initially preset in the MOB_SLP-REQ message and the MOB_SLP-RSP message that the MS and the BS exchange.
(6) Ranging Request (RNG-REQ) Message
The RNG-REQ message can be used for controlling an operation of defining and activating/deactivating the power saving class. To this end, the RNG-REQ message comprises therein a compound Type-Length-Value (TLV) encoding which is the following power saving class parameter.
TABLE 6TypePHYName(1 byte)LengthValue (variable-length)scopePower_Saving_Class_Parameters21variableCompound TLV to specify—Power Saving Classdefinition and/or operation
As shown in Table 6 as an example, the compound TLV encoding comprises therein several IEs indicating characteristics of the power saving class, shown below in Table 7 as an example. As to the compound TLV encoding, the IEs described in connection with the MOB_SLP-REQ message are defined in the form of TLV encoding. Each TLV encoding IE is similar to that described in connection with the MOB_SLP-REQ message, so a detailed description thereof will be omitted.
However, for each TLV encoding IE, overhead of a total of 2 bytes—1 byte for a Type field and 1 byte for a Length field—additionally occur. In addition, when the MS performs definition, deactivation and activation on a plurality of power saving classes, there are as many TLV encodings as the number of power saving classes.
When the MS performs handover, i.e., performs network re-entry, it can only perform the definition on the power saving class to a target BS. In other words, the MS cannot simultaneously perform definition and activation on an arbitrary power saving class before it completes the network re-entry. That is, the MS performs definition on the power saving class, and after completing the network re-entry, redefines the power saving class using the RNG-REQ message or performs activation. The MS can perform redefinition, activation and deactivation through transmission/reception of the MOB_SLP-REQ/MOB_SLP-RSP messages. In addition, after completion of the network re-entry, the MS can perform redefinition, activation and deactivation using the BW-REQ and UL Sleep Control header or the DL Sleep Control Extended Subheader.
TABLE 7TypeName(1 byte)LengthValue (variable-length)Power_Saving_Class21Assigned power saving classIDidentifier.Not used for RNG-REQ message.Power_Saving_Class_Type31Power saving class type as specifiedin 6.3.2.3.Start_frame_number41Start frame number for first sleepwindow.Not used for RNG-REQ message.initial-sleep51Initial sleep window.windowlistening window61Assigned duration of MS listeninginterval (measured in frames).final-sleep71Assigned final value for sleep intervalwindow base(measured in frames) - base.final-sleep81Assigned final value for sleep intervalwindow exponent(measured in frames) - exponent.SLPID91A number assigned by the BSwhenever an MS is instructed to entersleep mode.CID102Connection identifier to be includedinto the power saving class. Theremay be several TLVs of this type in asingle compound Power Saving ClassParameters TLV.Direction111Direction for management connection,which is added to power saving class.
(7) Ranging Response (RNG-RSP) Message
The BS transmits a response to the definition, deactivation and activation request for the power saving class based on the RNG-REQ message that the MS transmits, using the RNG-RSP message. In addition, the BS can transmit to the MS its command rather than a response to the request of the MS in an unsolicited manner. In other words, the BS can define, deactivate and activate the corresponding power saving class through the RNG-RSP message even without reception of the RNG-REQ message that the MS transmits.
To this end, a compound TLV encoding, which is a power saving class parameter shown in Table 8 as an example, is defined in the RNG-RSP message.
TABLE 8TypeValuePHYName(1 byte)Length(variable-length)scopePower_Saving27variableCompound TLV toAllClass_Parametersspecify power savingclass definition and/oroperation
TLV encoding IEs comprised in the compound TLV encoding use the TLV encoding IEs comprised in the compound TLV encoding of the RNG-REQ message in the same way. That is, when defining the power saving class of the sleep mode, the RNG-REQ message and the RNG-RSP message use different types of compound TLV encodings, but they can use the same type of TLV encoding IEs in the compound TLV encoding.
When the power saving class is defined as described above, a plurality of IEs are needed. However, the IEs comprised in the compound TLV encodings of the RNG-REQ message and the RNG-RSP message do not comprise all IEs that define the power saving class. That is, not all IEs that define the power saving class in the MOB_SLP-REQ message and the MOB_SLP-RSP message are defined in the compound TLV encodings of the RNG-REQ message and the RNG-RSP message.
Table 9 shows an example of a comparison in IEs between the MOB_SLP-REQ message/MOB_SLP-RSP message and the RNG-REQ message/the RNG-RSP message.
TABLE 9PSC parametersMOB_SLP-in RNG-REQ/RSPREQ/RSPNoteSleep_Approved—/0Not RequiredOperation0/00/0Definition0/00/0Start_Frame_Number0/00/0When Operation = 1Stop CQI Allocation—/0—/0When Operation = 1FlagPower Saving Class ID0/00/0Power_Saving Class0/00/0When Definition = 1TypeDirection0/00/0When Definition = 1TRF-IND-Required0/00/0When Definition = 1Traffic_Triggered_Wakening_flag0/0When Definition = 1and Power SavingClass Type = 1Initial-Sleep Window0/00/0When Definition = 1Listening-Window0/00/0When Definition = 1Final Sleep Window0/00/0When Definition = 1baseFinal Sleep Window0/00/0When Definition = 1exponentNumber_of_CIDs0/0Not RequiredWhen Definition = 1CID0/00/0When Definition = 1SLPID—/00/0When Definition = 1&& TRF-IND_Required = 1MDHO/FBSS duration—/0When MS supportsMDHO or FBSS
As shown in Table 9, the compound TLV encoding of the RNG-REQ message/RNG-RSP message does not comprise Sleep_Approved, TTWF, Number_of_CIDs, and MDHO/FBSS duration, which are IEs of the MOB_SLP-REQ message/MOB_SLP-RSP message. However, the IEs, which are not comprised in the RNG-REQ message/RNG-RSP message, should also be defined in the compound TLV encoding.
Meanwhile, the IEs comprised in the compound TLV encodings in the RNG-REQ message/RNG-RSP message are composed of 3 fields, namely Type, Length and Value. In order to indicate a type and a length of the Value field, 2-byte overhead, i.e., overhead of the 1-byte Type field and the 1-byte Length field, always occurs. In addition, since the IEs comprised in the compound TLV encodings in the RNG-REQ message and the RNG-RSP message are usually comprised, it is not possible to make the best use of the merits of the TLV capable of selectively comprising IEs. That is, no management problem occurs even though there is no Type and Length fields for the IEs comprised in the compound TLV encoding in the RNG-REQ message and the RNG-RSP message. Meanwhile, the RNG-REQ message/RNG-RSP message may occupy many frequency/symbol regions, when a lower Modulation and Coding Scheme (MCS) level is applied. Accordingly, there is a need for a system and method for transmitting and receiving ranging information in a sleep mode.